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ABSTRACT 



The invention provides solutions to the problems which are 
encountered by object oriented systems designers when 
attempting to implement schemes for object invocation and 
for argument passing in distributed systems wherein the 
arguments may be objects, and wherein the system supports 
a multiplicity of ORB-specific data formats, in ways which 
do not lock the object oriented base system into methods 
which may be difficult to change at a later time. Moreover, 
the invention disclosed describes a "Marshal Buffer mecha- 
nism" which contains methods for marshaling data for a 
specific ORB; a "Multi-ORB Marshaling system" which 
permits a Client Application and related stub to invoke an 
operation on a target object without any knowledge or 
concern about which ORB this target object uses or what 
data format the ORB requires for the arguments of the 
operation invoked; and a "Computer system for multi-ORB 
communication" comprising an ORB independent layer 
which contains Client Applications and stubs; an ORB 
dependent-OS independent layer which contains ORB 
dependent code/Subcontract code mechanisms as well as 
ORB specific Marshal Buffers for a multiplicity of ORBs; 
and an Operating System (OS) layer. 

21 Claims, 7 Drawing Sheets 
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MTTHOn AND APPARATUS FOR such as Mosaic will down-line load an HTML document and 

^TS^E^CCTW« TO &en wait passively for a human user to either select another 

^SSSSSSi IN document to enter Him forms information that can be 

OBJECT REFERENCE SPECIFIC DATA passed back to the server. 

FORMATS 5 Two new developments are promising to make the Inter- 

net a more dynamic environment. The first is support for 
BACKGROUND OF THB INVENTION scripting languages in Internet browsers (such as the Sun 

Microsystems, Inc. (SUN) JAVA language described below) 
1. Field of the Invention so that a browser can download and execute interactive 

The present invention relates to the fields of distributed 10 saipt ^ j^as transforms browsers from being passive view- 
computing systems, client-server computing and object ori- m into dynamic agents mat can interact with the 
ented programming. Specifically, the present invention is a internet on a user's behalf and display rapidly changing 
method and apparatus for providing program mechaiiisms information. Hie second development is the widespread 
which allow generic stubs to marshal and unmarshal data in adoption of the Object Management Group's distributed 
object-referenoe-specific data formats. 15 interfaces based on the IDL interface definition lan- 

nAPKfTROUND guage. These provide a standard way for network servers to 

BACKGROUND expQrt sayict& ^ "network objects- in a language and 

A key problem in modern object oriented distributed vendor independent way. This will make it much easier to 

processing systems is permitting object applications to com- build network services mat can be transparently accessed 
municate with a new object request broker ("ORB") which 20 from different client environments, 

has its own unique data format, with only minor modifica- j ftva 

tion to the supporting code mechanisms. Similarly client j aya fe a typed object-oriented language with a C 

applications and stubs should be able to communicate seam- syntax. The Java compiler and run-time code raccha- 

lessly with different ORBs in a system which can commu- type safety so mat there can be no wild 

nicate with a multiplicity of ORBs wherein each of the 23 „ references that violate the language's type 

ORBs has its own unique data format system. So for example, there is no 'Void » n and all casts are 

For example, the Object Management Group (OMG) is an validated at runtime, 
industry standards organization that is creating multi-vendor ^ j ava language is typically compiled to machine- 
standards for distributed object-oriented programming. One independent byte-codes and then a Java virtual machine 
of the cornerstones of the OMG work has been the definition 30 m terprets those byte codes in order to execute the Java 
of a common Interface Definition Language, known as IDL, program, Java can be integrated into network HTML 
that is now in widespread use as a standard way for defining browsers, so that as part of viewing a document one can 
interfaces to network objects in a way that is independent of down-line load a set of Java byte-codes and then execute 
the particular network protocols that are being used or the mem ^ the client machine. Because Java is completely 
particular programming languages that are being used by the 35 typesafe the client browser can feel confident that the Java 
clients and the servers. program can be executed safely without endangering the 
The IDL language is object-oriented and supports mul- security or integrity of the client Java is more fully 
□pie inheritance. It comes with a rich set of built-in primitive described in The Java Language Specification" release LO 
types (such as floats, booleans, etc.) and also defines a set of Alpha3, by Sun Microsystems, Inc. dated May 11, 1995 
structured types including structt, unions and sequences. which is hereby fully incorporated herein by reference. 

The Object Management Group standardized on the IDL Scripted language systems like Java generate Java pro- 
interface definition language as a uniform way of defining grams that are designed to be portable and to be deployed in 
interfaces to network objects. However, the OMG initially a variety of different eirvironments. It is therefore desired to 
left the on-the-wire protocol and data formats undefined. As ^ allow Java programs to use different ORBs without requir- 
a result different vendors implemented ORBs with different m g any changes to the Java program. Because the generated 
protocols and different data formats. stubs are part of the Java program it is necessary that the 
Recently the OMG has agreed on a common ORB inter- stubs be ORB-independent so that the Java program and its 
operabUity protocol, the Universal Networked Objects associated stubs might be used in any of a multiplicity of 
(UNO) protocol. However this is primarily viewed as a 50 ORBs. . 
gateway protocol for connecting object systems from dif- This disclosure describes a solution to the basic problem 
ferent vendors. At least in the short term different vendors by creating a generic interface between the stubs and ORB 
appear likely to continue to use their existing protocols for specific data mechanisms. These ORB specific data mecha- 
higher performance within their own object systems, while nisms include one or more Marshal Buffer Objects which 
supporting lower performance UNO gateways to other 5J have methods for marshaling and unmarshalling one or more 
ORBs. Thus a current need exists to permit object applica- particular ORB related on-the-wire data formats and a 
dons to transparently communicate with these ORBs with method and apparatus for using an object reference (Objref) 
different protocols and different data formats. to indicate the particular Marshal Buffer Object to use for 

For further description of object oriented design and this particular Object call 

programming techniques sec Object-oriented Software 60 SUMMARY OF THE INVENTION 

Construction" by Bertrand Meyer, Prentice-Han 1988. For WMMARI 

further information on OMG, CORBA, ORBs and IDL see The present invention provides an elegant and simple way 

the "Common Object Request Broker. Architecture and to provide mechanisms for invocation of objects by client 

Specification"* Revision 2.0, July 1955 which is hereby fully applications and for argument passing between client appli- 

incorporated herein by reference. 65 cations and object implementations, without the client appli- 

Currently Internet browsers are very limited in their cation or the operating system knowing the details of how 
ability to interact with network servers. TVpically a browser these niechanisms work. Moreover, these mechanisms rune 
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tions in a distributed computer environment with similar quantities take the form of electrical or magnetic signals 
ease and efficiency, where client applications may be on one capable of being stored, transferred, combined, compared, 
computer node and object implementations on another. and otherwise mnnipnlatrri It proves convenient at times, 
In one aspect of the invention, a "Computer system for principally for reasons of common usage, to refer to these 
multi-ORB communication-' is disclosed which includes an > signals as bits values elements symbols characters terms^ 
Object Request Broker (ORB) independent layer which oumbers. or the like. It should be noted, however, that all of 
contains Client Applications and stubs; an ORB dependent- *> d terms are to be associated with the appro- 
OS Independent layer which contains ORB dependent code/ V™* physical quantities and are merely convenient labels 
Subcontract code mechanisms as well as ORB speculc applied to these quantifies. 

Marshal Buffers for a multiplicity of ORBs; and an Oper- 1° Further, the manipulations performed are often referred to 
atlng System (OS) layer. In terms, such as adding or comparing, which are commonly 
In another aspect a "Multi-ORB Marshaling system" is associated with mental operations performed by a human 
disclosed which permits a Client Application and related operator. No such capability of a human operator is 
stub to invoke an operation on a target object without any necessary, or desirable in most cases, to any of me opera- 
knowledge or concern about which ORB this target object 15 dons described herein which form part of the present inven- 
usesorwhatdatafcrmatmeORBreo^formearguments *e operations are machine operations. Useful 
of the operation invoked. machines for performing the operations of toe present inveo- 

In yet another aspect, the invention disclosed describes a £° * clude gCW ™ 1 pU * p0Se C ° afMm " 

"Marshal Buffer mechanism* 1 which contains methods for „ ' , _ _ 

marshaling data for a specific ORB. ™ c P*** invention also relates to apparatus for pa- 

„ , , . » framing these operations. This apparatus may be specially 

In another aspect of the invention, a computer formed ^o«ed fc Xreqiiired purJcieTor it may comprise a 

method of processing «uls from a chent wUcahon to an corn^^Sdvely activated cTW 

ORB requiring a specific data format is disclosed wherein * byTccnm^er program stored In the computer. Hie 

me c^ent whe^on and Us ^ * S hereHc not InherenUyXted to a 

know which ORB is being used or which format Is rcqmrcd a ^ various general 

for the data. The method includes a process for finding a ^ZJ?ZTfU „^ wo «JL n :„ 

w . . ^ r . * i . purpose machines may be used with programs written in 

MarshalBuffer which can provide the correct data fonnat K«*t~ ' «. . « „^ 

77 , _rt«Ti accordance with the teachings herein, or it may prove more 

marshaling for the correct ORB. convenient to construct more specialized apparatus to per- 
Similarly, the claimed invention includes a computer 30 form mc requ^ method steps. The required structure for a 

program product embodying these inventive mechanisms. varicty 0 f these machines will appear from the description 

DESCRIPTION OF THE DRAWINGS givcn * 

The objects, features and advantages of the system of the DESCRIPTION OF THE PREFERRED 

present invention will be apparent from the following 35 EMBODIMENT 

description in which: The following disclosure describes solutions to the prob- 

FIG. 1 illustrates the configuration of a typical computer which m encountered by object oriented systems 

hardware system used with and as a part of the present designers when attempting to implement schemes for object 

invention. ^ invocation for argument passing in distributed systems 

FIG. 2 illustrates the prior art relationship of client and wherein the arguments may be objects, in ways which do not 

server applications to stubs and network software. lock the object oriented base system into methods which 

FIG. 3 illustrates a system showing Java ORB classes. may be difficult to change at a later time. Moreover, the 

FIG. 4 illustrates the relationship between stub objects, invention ^closed describes a "Marshal Buffer mec*a- 

ORB specific code/subcontract mechanisms, and server « which contains operations (called "niefcods in 

appticati^jects in a single ORB system. ^^^^f^^^ marshaling data 

^^V,.. . _ \V s ^ - ™>n ^ a specific ORB; a 'Multi-ORB Marshaling system" 

9; 5 JH u f^ ™«* location using ORB which a ^^oa and related stub to 

specific code/subcontracts, ORB-specific MarshalBuffer ^ opcratioil on a ^ object without any knowl- 

medianisms in a multi-ORB system. M edge or concern about which ORB this target object uses or 

FIG. 6 illustrates an exemplary MarshalBuffer code what data format the ORB requires for the arguments of the 

Mechanism. operation invoked; and a "Computer system for multi-ORB 

FIG. 7 illustrates a more specific remote object invocation communication" comprising an ORB independent layer 

using ORB specific cooVsubconrracts, ORB-speciflc Mar- which contains Client Applications and stubs; an ORB 

shalBuffer mechanisms in a multi-ORB system. 55 dependent-OS independent layer which contains ORB 

dependent code/Subcontract code mechanisms as well as 

NOTATIONS AND NOMENCLATURE 0 RB specific Marshal Buffers for a multiplicity of ORBs; 

The detailed descriptions which follow may be presented and an Operating System (OS) layer. The "ORB dependent 

in terms of program procedures executed on a computer or code mechanism" used in the present invention, is analogous 

network of computers. These procedural descriptions and 60 to the "subcontract rnecrianism" which is associated with 

representations are the means used by those skilled in the art each object and which is described in co-pending patent 

to most effectively convey the substance of their work to application Ser. No. 07/995,863 filed Dec 21, 1992 which is 

others skilled in the art incorporated fully herein by reference. 

A procedure is here, and generally, conceived to be a In the following description, for purposes of explanation, 

self-consistent sequence of steps leading to a desired result 63 specific data and configurations are set forth in order to 
These steps are those requiring physical manipulations of provide a thorough understanding of the present invention, 

physical quantities. Usually, though not necessarily, these The preferred erribodiment described herein is implemented 
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as a portion of the SPRING-DISTRIBUTION Object- 
Oriented Operating System created by Sun Microsystems®, 
Inc. (Sun Microsystems is a registered trademark of Sun 
Microsystems, Inc.) However, it will be apparent to one 
skilled in the art mat the present invention may be practiced 
without the specific details and may be implemented in 
various computer systems and in various configurations, or 
makes or models of tightly-coupled processors or in various 
configurations of loosely-coupled multiprocessor systems. 
The Spring-Distribution Object-Oriented Operating System 
is described in **A Spring Collection** A collection of Papers 
on the Spring distributed Object-Oriented Operating System 
published September 1994 by sun Microsystems, Inc. which 
is hereby fully incorporated herein by reference. 

ADDITIONAL BACKGROUND INFORMATION 

Operating Environment 

The environment in which the present invention is used 
encompasses the general distributed computing system, 
wherein general purpose computers, workstations, or per- 
sonal computers are connected via communication links of 
various types, in a client-server arrangement, wherein pro- 
grams and data, many in the form of objects, are made 
available by various members of the system for execution 
and access by other members of the system. Some of the 
elements of a general purpose workstation computer are 
shown in FIG. 1, wherein a processor 1 is shown, having an 
Input/output ("I/O") section 2, a central processing unit 
("CPU") 3 and a memory section 4. The I/O section 2 is 
connected to a keyboard 5, a display unit 6, a disk storage 
unit 9 and a CD-ROM drive unit 7. The CD-ROM unit 7 can 
read a CD-ROM medium 8 which typically contains pro- 
gram code mechanisms 10 and data. 

Stubs 

Techniques for providing a language-level veneer for 
remote operations (for example, "Remote Procedure Calls") 
have been in use for many years, "typically these take the 
form that a remote interface is defined in some language. 
Then a pair of stubs arc generated from this interface. The 
client stub runs in one machine and presents a language level 
interface that is derived from the remote interface. The 
server stub runs in some other machine and invokes a 
language-level interface that is derived from the remote 
interface. Referring now to FIG. 2, to perform a remote 
operation, a client application 12 on one rnachine 11, 
invokes the client stub 14, which marshals the arguments 
associated with the invocation into network buffers) and 
transmits them to the server stub 22 on the remote machine 
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this data back into a new object This has several serious 
deficiencies. First, it is a violation of the "abstraction" 
principle of object-oriented programming, since stubs have 
no business knowing about the internals of objects. Second, 
it requires mat the server and Che client implementations of 
the object use the same internal layout for their data struc- 
tures. Third, it may involve marshalling large amounts of 
unnecessary data since not all of the internal state of the 
object may really need to be transmitted to the other 
machine. An alternative solution is that when an object is 
marshalled, none of its internal state is transmitted. Instead 
an identifying token is generated for the object and this 
token Is transmitted. For example in the Eden system, 
objects are assigned names and when an object is marshalled 
then Its name rather than its actual representation is mar- 
shalled Subsequently when remote machines wish to oper- 
ate on this object, they must use the name to locate the 
original site of the object and transmit their invocations to 
that site. This mechanism is app ropriate for heavyweight 
objects, such as files or databases, but it is often inappro- 
priate for lightweight abstractions, such as an object repre- 
senting a cartesian coordinate pair, where it would have been 
better to marshal the real state of the object Finally, some 
object-oriented prograrnming systems provide the means for 
an object implementation to control how its arguments are . 
marshalled and unmarsfaalled. For example, in the Argus 
system object implementors can provide functions to map 
between their internal representation and a specific, 
concrete, external representation. The Argus stubs will 
invoke the appropriate mapping functions when marshalling 
and unmarshaling objects so that it is the external represen- 
tation rather than any particular internal representation that 
Is transmitted. These different solutions all either impose a 
single standard marshalling policy for all objects, or require 
that individual object implementors take responsibility for 
the details of marshalling. An advanced object marshaling 
process is described in the above referenced co-pending 
patent application Ser No, 07/995,863 filed Dec 21, 1992 
which describes "Subcontracts." 
Current Problem Summary 

Specific Problem for Current Object Oriented Systems 
The specific problem here is that different ORBs have 
different on-the-wire data formats. So one ORB might 
marshal bytes in little-endian order, another in big-endian, 
etc Different ORBs also have different on-the-wire formats 
for arrays, strings, unions, etc. 

So it is desirable to have ORB independent stubs that can 
marshal their data differently when talking to different 



objects. Thus, one might use a DEC data format when 

18, whi* unmarshals the arguments from the network x *±^*^L\^^tT£^^ 
buffos) and calU me server appUcation 24. Similar* when » a J™*^^^ 
the server application 24 returns a response, the results are 
marshaled up by the server stub 22 and returned to the client 
stub 14, which unmarshals the results and returns them to the 
client application 12. The entire mechanics of argument and 55 
result transmission, and of remote object invocation, are 
performed in the stubs. Both the client application and the 
server application merely deal in terms of conventional 
language-level interfaces. 

When the arguments or results are simple values such as 60 
integers or strings, the business of marshaling and unmar- 
shalling is reasonably straightforward. The stubs will nor- 
mally simply put the literal value of the argument into the 
network buffer. However, in languages that support either 
abstract data types or objects, marshalling becomes signifi- 65 
cantly more complex. One solution is for stubs to mar s h al! 
the internal data structures of the object and then to marshal 



set of stubs to be in simultaneous use with different ORBs. 
Proposed Solution to the Problem 
The solution is; 

(1) define a generic interface for marshalling. This generic 
interface provides methods for marshalling and mar- 
shalling ints, shorts, bytes, chars, and strings. But it 
says nothing about how these methods are imple- 
mented. 

(2) Different ORBs provide their own implementation of 
the generic marshal buffer interface. As well as sup- 
porting the generic marshalling and unmarshalling 
methods, these ORB specific marshal classes may 
provide additional methods for marshaling ORB spe- 
cific data. For example the Spring ORB implementa- 
tion of MarshalBuffer provides methods for marshal- 
ling and unmarshalling Spring doors. 
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(3) Each object reference (Objref) contains a pointer to a Unfortunately, the different transport protocols also come 
set of ORB runtime machinery that belongs to the ORB with different data formats for simple data types. For 
that implements that object In the preferred implemen- example, integer values may have to be transmitted in 
tation this consists of a pointer to the client side big-endian byte order for an ONC ORB and In little-endian 
ORB-dependent code mechanism/subcontract for the 5 byte order for a DCE ORB. This affects the way that one can 
object. marshal and unmarshal arguments from the marshal buffers. 

(4) The ORB runtime machinery described in (3) will At the next level up, even if two ORBs agree on a standard 
support a method for obtaining a MarshalBuffer object format for simple data types, they may disagree on how to 
The runtime machinery will return a MarshalBuffer handle the IDL structured data types. For example both the 
object that implements the correct marshalling and "> Spring ORB and the DOB ORB use the ONC XDR format 
unmarshalling for mat ORB. for simple data types, but when they transmit an array 

(5) The generic stubs work entirely in terms of the generic descriptor the DOE ORB simply transmits an integer sped- 
MarshalBuffer interface. tying the length, whereas the Spring ORB transmits two 

(6) At the beginning of each call, the generic stubs call integers, one specifying the array's lower bound and the 
into the ORB specific runtime code mechanisms asso- 15 other specifying the array's upper bound. This means that if 
dated with the object reference to get an appropriate one wants to have stubs that can be used between i different 
MarshalBuffer object The stubs then use the generic 0RBs meD me stUDS «« 1 dircctl y ^8* Hke array 
marshaling and unmarshalling interfaces to marshal descriptors, but instead must call into some ORB specific 
and unmarshal data to and from that MarshalBuffer code - 

object. Since the implementations of these marshal and Finally there are likely to be different formats for the 

unmarshal methods are ORB specific, this means mat various kinds of IDL related meta-data, such as object 

the data is being marshalled and unmarshalled in an references, method identifiers, exception identifiers, and 

ORB specific way. type identifiers. For example, Spring uses integers as method 

In the currently preferred embodiment, the generic Mar- identifiers. Other ORBs send either a simple method name 

shalBuffer includes additional capabilities for handling dif- 25 of a fully qualified interface name plus method name com- 

ferences in several known ORBs. For example, (a) in binau'on. 

addition to methods for marshalling and unmarshalling The Portability Strategy 

simple data types, the generic MarshalBuffer provides a way |q me preferred embodiment the general strategy has 

for Marshalling array descriptors. This method takes the ^ been to create stubs mat are ORB independent and to 

bounds of the array and then marshals an array descriptor in conceal the ORB dependencies inside the individual object 

an ORB specific way. For example, the DOB ORB code references. Ibis has the major advantage that a single Java 

marshals the length of the array. But the Spring ORB code sn j D compiler can be used that can generate stubs that can be 

marshals the lower bound and the upper bound, and (b) usc< j with any ORB. However this means mat there must be 

similarly provides mechanisms for umnarshalling an array ^ interfaces between the stubs and the object reference that 

descriptor. allow the stubs to marshal arguments and invoke remote 

HOW TO MAKE AND USE THE INVENTION operations in an ORB independent manner, 

_ , . Experience with using the subcontract mechanism in the 

A Portable ORB Implementation Spring system was used in designing the separation between 

One of the goals for the preferred embodiment of the ^ me ^ mc qrb specific layer. Spring permits differ- 

presenl invention is for the Java ORB implementation to be ^ ^ ^ references to have different formats and to have 

allowed to work directly with a variety of different on-the- different invocation tp^*™*™^ so as to be able to support 

wire protocols and data formats. In particular, a single Java ^ replication and data caching. It does mis by 

program must be able to simultaneously use object refer- associating a software module called a subcontract with each 

ences that refer to objects in different ORBs. The internet is 4S object reference. When the Spring stubs want to marshal or 

a very heterogeneous environment and it is desired not to invoke an object reference, they call into the subcontract 

restrict Java IDL clients to only working with a single server associated with the object reference, so mat the marshalling 

at a time. or object mvocation is performed in a way mat is appropriate 

In particular the Java ORB implementation of the pre- to that subcontract 

fared einbodiment must be able to coinmunicate directly M ^ mc JAVA 0RB implementation of the preferred 

with both Sun's Distributed Object Environment (DOE) and embodiment ^ €Xtr& abstract interface was added so that 

with the Spring distributed operating system. It is also a singlc sct of stubs colAd communicate with multiple 

desired to design the Java ORB core so that it could 0RBs M abstract MarshalBuffer interface was added and 

communicate with UNO gateways or with DCE based object mc ^ Marshaffiuffcrs was moved from the stubs 

systems. 55 into the subcontracts, so that different ORBs could provide 

Portability Issues different sub-classes of MarshalBuffer which marshalled and 

Portability is an issue at several different levels. unmarshalled data in the correct format for that ORB. FIG. 

At the lowest level, Java's socket class is used to get 3 provides an illustration of the Java ORB classes. In FIG. 

machine and OS independent access to the IP protocol 3, A Java Application 70 uses a set of stubs 68 to talk to a 

family. eo set of remote objects (not shown). These stubs and applica- 

At the next level up, different ORBs use different low- tions comprise an "ORB Independent" layer 69 which 
level network transport protocols. For example, Sun's DOE interface gencrically with the "OS Indepcndent/ORB depen- 
sy stems uses ONC RPC, the Spring system uses an opti- denf layer 61. An exemplary "OS Independent/ORB depen- 
alized sequenced packet protocol, UNO uses TCP/IP, some dent" layer 61 comprises, for example, two different Spring 
other vendors use DCE RPC, etc. However, while this may 65 subcontract mechanisms 66, 64 that use the same Marshal- 
seem like fairly major difference it is actually comparatively Buffer 60 and the same Spring network protocol code 
easy to plug in different low level transport protocols. mechanism 56 to talk to the remote object (not shown). An 
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ORB dependent code mechanism 62 for use by Sun's DOB functionality of me ORB dependent wdc m inarshaling and 
ORB isshown, which uses a DOB MarshalBuffer 58 which umnanhalllng data. The stubs understand the Pj^cular set 
in turn uses the DOE network protocol code mechanism 54. of arguments or results that are 

In this example, both the Spring network protocol code calL The stubs then call into die ORB dependent code 
SecEuib^ud >be DOB network protocol code mecha- 5 mechanism that implements the MarshalBuffer interface in 
nism 54 use the Java network "Socket" code mechanism 51 order to marshal (ox unmarshal) each data item contamed to 
(The Java "Socket" class provides access to TCP/IP and the arguments or results. The ORB dependent code tnecha- 
UDP functionality in a way that is broadly similar to me nism knows nothing about the JDL interface but simply 
sockets interfaces provided in the Berkeley UNIX marshals each data item in the correct format for mat target 
distributions.). This Java network "Socket" code mechanism w ORB. Key concepts in the preferred embodiment are that (1) 
52 uses Operating System (OS) services 51 from whatever the MarshalBuffer interface such as shown in FIG. 6 is an 
nskis ninmneon Interface which different ORBs can provide their own imple- 

'V ™ i„ te rf ace mentation for. and (2) the ORB dependent code provides the 

The MarshalBuffer Interface MarshalBuffer object to the stubs. 

In the preferred embodiment the interface between trie , . . , . .„, rf 

stutand&arsh^^ - ^1^^^^ 

stubs not onJy '™^ t ^£^^J»^X Susttated) might use Spring's Singleton subcontract 408. 
and long, but are also given control over how structured IDL s KotIW 4*S come to make a call on one of 

data types were marshaUed. ^^'^'^ JJS» ?»3^£yW«k the subcontract 408 to give 
MarshalBuffer methods for niarsbaUing and unniarshalling ^ ^^^^ The Singleton subcontract 408 will 
array headers and union discriminators. ^ g SpringMalshalBuffer4 10 that will obey the Spring 

Putting me Pieces Together on-the-wire data formats. The stubs 406 then marshal the 

In the context of the present invention different appUca- method arguments into that marshal buffer 410. After the 
tions may call objects or send data to objects which have 444 Qave marshalled all the arguments, they call into 

implementations that are associated with different ORBs but 2s the Subcontract 408 to actually transmit the method invo- 
in this case using ORB-in dependent code/subcontract cation to the server. The Singleton subcontract 408 uses the 
mechanisms to determine the target ORB, to find a Mar- Spring network protocol handlers 412 to transmit the request 
shalBuffer that knows how to marshal the data for the target to me Spring server and get the results. The stubs 4M can 
implementation and to communicate with the machine con- the results from the MarshalBuffer 410 and 

taining the target implementation. Referring now to FIG. 5, 30 jetum them to the client application 402. 
the client application 112 again Issues the cad on stub 112. ^ ^ embodiment, a stub compiler contojava 

In mis instance however, the stub 112 sends the call to an ^ co^etc Java client stubs for IDL interfaces 

ORB-specific code/subcontract mechanism 212 determined fa u ^ 

in the preferred embodiment by an inoacatton in&e o^ref. worklng , ava ORB implementation that can 

(An alternative embodiment wo^ Include some ORB-ID 35 ^mmicate^ with bom DOB and Spring servers is used, 
mechanism for identifymg ^ ORB-specific «* ^mecha- ^ to Spring includes two subcontracts 

nism required by a spedflc object caU. where MsOI^ID ™«Me ^ ^ JflVa implementation of 
mechanism might be specified when the object inmlemen- protocol. The code for talking to 

tation is created and used each time this object is called ^^^7^ (for the Basic Object 

thereafter. Those skilled in the art will recognize that there «, VJj^^^ *7code for locating and activating DOE 
are many ways to identify the ORB-specUlc code required *S^SS^tmORB ^ uWn in Java and is 
by an Object reference ) This mf^*^etween different Java environments. K is believed 

Mbc onjract mechanism 212 determines whan famatU ORB core could be easily extended with subcon- 

icquired by the target ORB and provides a MarshalBuffer pacts that could talk to UNO or to ORBs Implemented by 
Object 210 capable of doing the correct marshalin g, notify- 45 "~ ,~~ 

ins the cKent stub 114 of which MarshalBuffer Object 210 cflier yenoots. , tmnr , . 

"to be used. The client stub 114. using this MarshalBuffer While the invention has been described in terms of a 
O^e* 2 M , nSuus the data and sends it to the network preferred ertotfoettj a spe^c operating system 
software code mechanism/device 116 as before. On the environment, those skilled in the art will recognize mat the 
server ride m target ORB-spedflc code mechanism 214 „ invention can be i*"***^ f 8 *^. £ 
knWs how to unmaVshal the tola and passes it to me different operating systems within the smnt and scope of the 
Unmarshal Buffer 216 which in the case of a Java transmis- ar^nded claims. 

rion may be a virtual mactime to interpret the byte-code data What is claimed is: 

execution by the server machine. L A computer system having a processor, a memory, a 

tor execution oy me server maomic „ display device, an input/output device, an operating system 

In meprefcrredembocliment, for any TOL^e* reference 55 ^Ti^^^Zg^a eoit mechanism invocations 
of type FOO, we provide a Java stub class FOO ^ coiri* ^ „SSiSWof. mumpUcity of remote Object 
of a set of stub methods and pointer to a subcontract object * (0 RBs), the computer system comprising: 

object, and these suDcontracTobjects may have different a program appucaoons and related flubs, and 

implementations, allowing them to talk to different ORBS. an ORB dependent layer of code mechanisms, coupled to 

When the stub methods wish to make an object invocation me ORB independent layer, the ORB dependent layer 

they ask the subcontract to give them a suitable Marshal- comprising 

Buffer object and then use that MarshalBuffer to marshal the program code mechanisms which are ORB-speoflc and 

arguments and marshal the results. An exemplary Marshal- 65 which are configured to generate a^hd code 

Buffer is shown in FIG. 6. The MarshalBuffer interface mechanism to marshal data in an ORB required 

shown In FIG. 6 represents a clean separation between the format and. 
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program code mechanisms configured to use a specific 
network protocol code whereby a program applica- 
tion code mechanism from the ORB independent 
layer can invoke a call on a remote implementation 
program code mechanism and the ORB- specific pro- 
gram code mechanisms in the ORB dependent layer 
will determine an appropriate marshal code mecha- 
nism to marshal data in an ORB required format; 
thereby providing a computer system capable of commu- 
nicating with a multiplicity of ORBs wherein each 
ORB requires data to be in a specific format 

2. A computer system as defined in daim 1 wherein the 
ORB independent layer of code mechanisms including pro- 
gram applications and related stubs comprise object appli- 
cations and related stubs. 

3. A computer system as defined in daim 1 wherein the 
marshal code mechanism to marshal data in an ORB 
required format which is located in the ORB-dcpendent 
layer is a MarshalBuffer Object configured to execute opera- 
tions to marshal data in an ORB specific format 

4. A computer system as defined in claim 1 wherein the 
program code mechanism configured to use a specific net- 
work protocol code communicates with a server computer 
comprising: 

a recdving program code mechanism comprising ORB 
dependent code configured to rective an object invo- 
cation from a remote computer system; and 

an ORB independent server application whereby the 
receiving program code mechanism calls into the ORB 
independent server application, passing in a Marshal- 
Buffer that allows the server application to unmarshal 
arguments and marshal results without having to know 
which ORB a call came from, 

5. A multi-ORB marshaling system for use in a computer 
node which contains client applications and related stubs for 
communicating with remote computer nodes which contain 
object implementations, the multi-ORB marshaling system 
comprising: 

an ORB- specific program code mechanism configured to 
receive an invocation of a target object implementation 
by an invoking client application, the invocation being 
received from a stub related to the invoking client 
application, wherein the invoking client application and 
the related stub have no knowledge of an ORB which 
must process the invocation, the ORB -specific program 
code mechanism configured to select one of a multi- 
plicity of MarshalBuffer program code mechanisms; 
and 

a MarshalBuffer program code mechanism, coupled to 
said ORB-specific program code mechanism config- 
ured to receive an invocation of a target object 
implementation, said MarshalBuffer program code 
mechanism configured to marshal arguments and data 
into a specific format required by the ORB which must 
process the invocation. 

6. A MarshalBuffer program code mechanism for use in a 
computer node which contains client applications and 
related stubs for communication with remote computer 
nodes which contain object implementation, the Marshal- 
Buffer program code mechanism comprising: 

program code mechanisms configured to format argu- 
ments and data related to an object implementation 
invocation made by a client application having a related 
stub, wherein said invocation and said client applica- 
tion and said related stub have no knowledge of an 
ORB which can process said invocation and wherein 
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said invocation and said client application and said 
related stub have no knowledge of a data format 
required by said ORB which can process said invoca- 
tion. 

7. A method of operating a computer system having a 
processor, a memory, a display, an input/output mechanism, 
an operating system and at least one client application 
program, one or more stub programs related to the client 
application, the method performed by the computer com- 
prising the steps of: 

invoking a call on a program implementation code 
mechanism, the call invocation being made by a client 
application wherein the call indudes a reference to the 
program implementation code mechanism; 

using a stub program code mechanism which is related to 
the client application to receive the call invocation, 
wherein the stub program code mechanism has no 
knowledge of a format required for marshaling data 
provided by the client application in connection with 
the call invocation; 

calling a first specific program code mechanism by the 
stub program code mechanism, requesting the first 
specific program code mechanism to provide a Mar- 
shalBuffer cede mechanism that knows how to format - 
data provided by the client application in connection 
with the call invocation; 

marshaling the data provided by the client application in 
connection with the call invocation, the marshaling 
being done by the stub program code mechanism using 
the MarshalBuffer code mechanism; and 

sending the call invocation to a server containing the 
program implementation code mechanism which is the 
target of the call 

8. The method described in claim 7 comprising the 
additional step of unmarshalling results from the 
MarshalBuffer, the results supplied by the program imple- 
mentation code mechanism which was called by the invo- 
cation. 

9. The method described in claim 7 wherein the first 
specific program code mechanism called by the stub pro- 
gram code mf*ft»"fo™ is an Object Request Broker (ORB) 
specific code mechanism. 

10. The method described in claim 8 wherein the stub 
program code mechanism which calls the ORB specific code 
mechanism has no knowledge of the ORB which will 
process the call 

11. The method described in claim 7 wherein the Object 
Request Broker (ORB) is an Object Management Group 
(OMG) Common Object Request Broker (CORBA) com- 
pliant ORB. 

12. A computer program product comprising a computer 
system usable storage medium having computer readable 
code embodied therein for causing a computer system to 
process program code mechanism invocations which are 
directed to one of a multipUtiry of remote Object Request 
Brokers (ORBs), the computer program product comprising: 

a first computer readable program code mechanism con- 
figured to comprise an ORB-independent layer of code 
mcrhflnterps induding client applications and related 
stub program code mechanisms; and 
a second computer readable program code mechanism 
configured to comprise an ORB dependent layer of 
code mechanisms, coupled to the ORB independent 
layer, the ORB dependent layer comprising program 
code rp'^flnkins which are ORB- specific and which 
are configured to generate a marshal code mechanism 
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to marshal data in an ORB required format and pro- 
gram code mechanisms configured to use a specific 
network protocol code whereby a program application 
code n w**fl"*CT" from the ORB independent layer can 
invoke a call on a remote implementation program code 
mechanism and the ORB-spedfic program code 
mechanisms in the ORB dependent layer will deter- 
mine an appr op r iate marshal code mechanism to mar- 
shal data in an ORB required format, thereby providing 
a computer system capable of cornmunicatiog with a 
multiplicity of ORBs wherein each ORB requires data 
to be in a specific format 

13. A computer program product as defined in claim 12 
wherein the ORB independent layer of code mechanisms 
including program applications and related stubs comprise 
object applications and related stubs, 

14. A computer program product as defined in claim 12 
wherein the marshal code mechanism to marshal data in an 
ORB required format which is located in the ORB- 
dependent layer is a MarshalBuffer Object configured to 
execute operations to marshal data In an ORB specific 
format 

15. A computer program product as defined in claim 12 
wherein the program code mechanism configured to use a 
specific network protocol code which is located in the 
ORB-dependent layer is configured to use a network pro- 
tocol code mechanism selected from a group consisting of 
Spring network protocol code and DOB network protocol 
code. 

16. A computer program product as defined in claim 12 
wherein the marshal code mechanism to marshal data in an 
ORB required format which is located in the ORB- 
dependent layer is also configured to unmarshal results 
returned to it 

17. A method for use in a computer node which contains 
client applications and related stubs for communicating with 
remote computer nodes which contain object implementa- 
tions wherein the computer implementations require invo- 
cation data to be in specific formats, the method, performed 
by (he computer, comprising the steps of: 

using an Object Request Broker (ORB>speeiflc program 
code mechanism configured to receive an invocation of 
a target object implementation by an invoking client 
application, the invocation being received from a stub 
related to the invoking client application, wherein the 
invoking client application and the related stub have no 
knowledge of an ORB which must process the 
invocation, the ORB-specific program code mechanism 
configured to select one of a multiplicity of Marshal- 
Buffer program code mechanisms; and 

using a MarshalBuffer program code mechanism config- 
ured to marshal arguments and data into a specific 
format required by the ORB which must process the 
invocation. 

18. A method for marshaling data into a specific format 
for use in a computer node which contains client applica- 
tions and related stubs for communicating with remote 
computer nodes which contain object implementations, the 
method for inanhaHng data, performed by a computer, 
comprising the steps of: 

providing marshal program code mechanisms associated 
with a plurality of Object Request Brokers (ORBs) 
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which require distinct data formats, the marshal pro- 
gram code mechanisms being configured to format 
arguments and data related to an object implementation 
invocation made by a client application, wherein said 
Invocation and said client application have no knowl- 
edge of an Object Request Broker (ORB) which can 
process said invocation and wherein said invocation 
and said client application have no knowledge of a data 
format required by said ORB which can process said 
invocation; 

selecting a particular marshal program code mechanism 
from the marshal program code mechanisms based 
upon a particular invocation; and 

using said selected marshal program code mechanism to 
marshal and unmarshal said arguments and said data. 

19. A computer system as defined in claim 1 wherein the 
ORB-dependent layer is also independent of the Operating 
System (OS) layer. 

20. The method of claim 7 comprising the additional steps 
of: 

receiving an object invocation from a remote computer 
system by a server-side ORB dependent code mecha- 
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issuing a call into an ORB independent server application, 
the call made by the server-side ORB dependent code 
mechanism which passes in a MarshalBuffer that 
allows the server application to unmarshal arguments 
and marshal results without having to know which 
ORB a call came from. 

21. A ccmputer-implemented method of operating a com- 
puter system having a processor, a memory, an operating 
system, and a client application, the method comprising: 

invoking a call on a target object, the call invocation being 
made by the client application wherein the call includes 
a reference to the target object, the target object being 
associated with a server application, the server appli- 
cation being associated with the computer system; 

using a stub which is related to the client application to 
receive the call invocation, wherein the stub has no 
knowledge of a specific format required for marshaling 
data provided by the client application in connection 
with the call invocation, the specific format required for 
muT tthaitiifl data being associated with the server appli- 
cation; 

calling a specific code mechanism using the stub; 

requesting & MarshalBuffer object from the specific code 
mechanism, the MarshalBuffer object being arranged to 
format the data provided by the client application into 
the specific format in connection with the call invoca- 
tion; 

mmhaling the data provided by the client application in 
connection with the call invocation, the marshaling 
being done using the MarshalBuffer object, wherein 
marshaling the data formats the data in the specific 
format; and 

sending the call invocation to the server application 
containing the target object 
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